Telecommunications networks are generally made up of multiple different domains. For example, a customer site including, for example, a telephone, may be one domain, a Local Exchange Carrier (LEC) (e.g., a Regional Bell Operating Company (RBOC), an Incumbent Local Exchange Carrier (ILEC) or a Competitive Local Exchange Carrier (CLEC)) including public telephone infrastructure equipment and physical layer network devices may be another domain and an IntereXchange Carrier (IXC) or Internet Service Provider (ISP) including upper layer network devices may be another domain. When problems occur on a network, detecting the source of a problem (often termed “trouble shooting”) as soon as possible is critical. Trouble shooting is made more efficient and effective when data being transferred between domains can be tested to determine in which domain the problem is arising.
Traditional equipment used in public telephone infrastructures include working ports that connect to cables coupled to customer sites and to cables coupled to LEC physical layer network devices. The telephone infrastructure connects the customer site cables and the physical layer switch cables to allow for data transfer between them. In addition, the infrastructure typically includes test ports connected to the working ports to assist in trouble shooting between the customer and LEC domains. Test equipment may be connected to one or more test ports or a patch panel connected to the test ports to monitor the signals being transferred over the different cables.
This is a very effective manner of testing because the data being tested/monitored is exactly the same as the data being transferred between the domains—that is, it is unmodified. In one manner of testing, test equipment may be set up in the customer domain to send data to the telephone infrastructure and test equipment may be connected to the patch panel to monitor the data received. The data sent may then be compared to the data received to determine if the data received was corrupted.
Though effective, this manner of testing is also labor intensive. Different test ports are connected to the patch panel through different cables that are connected to and disconnected from the patch panel to test different working ports. In addition, this test method does not scale well and may be expensive for as the size of the network grows, the number of cables and test ports must also grow. Moreover, patch panels cannot be used when the physical connections are optical fibers as the optical fiber cannot be split between a working port and a test port.
Since the patch panel method of testing does not scale well, higher density network devices and upper layer network devices do not normally implement that method of testing. Instead, often these more complex network devices provide the ability to steer data to a dedicated test port. Steering, however, is under software control and most of the device must be working properly to steer data to the test port. In addition, with regard to upper layer network devices, the data supplied to the test port is significantly modified as compared to the data delivered to the device. For example, any physical layer protocol information is generally striped off and, if provided, it has been regenerated.
As the data received is modified, it becomes more difficult to pin point the source of the problem. A comparison of data sent to data received at the test port may show differences but it will be difficult to determine if the data received by the device was corrupted before or after receipt. For example, signal strength, jitter and timing may be masked by the translations and processing performed by the network device.
In addition, dedicating a test port and steering data to that test port use valuable resources that might instead be used to transfer more network data. If the test port is not a dedicated test port, then the network device may need to be re-configured each time testing is to be performed. Re-configuration may require tearing down the test port connection(s) and then re-establishing new test port connections. This may disrupt services which are working properly.